I have this class in my code:
public class Schedule{
private List<ScheduleData> list;
public Schedule(){
list = new ArrayList<>();
}
public List<ScheduleData> getList(){
return list;
}
public void add(ScheduleData data){
list.add(data);
}
}
This class will have some methods to manipulate this ScheduleData list and compare its data to some other stuff.
My question is:
What is the better practice to add ScheduleData elements to my list? Using this method public void add(ScheduleData data) or doing it like the following code?
Schedule s = new Schedule();
s.getList().add(new ScheduleData());
I think that initially you have to try to satisfy basic principles of object orientation. One of these is information hiding.
Citing Wikipedia:
In computer science, information hiding is the principle of segregation, of the design decisions in a computer program that are most likely to change, thus protecting other parts of the program from extensive modification if the design decision is changed. The protection involves providing a stable interface which protects the remainder of the program from the implementation (the details that are most likely to change).
Probably, clients of Schedule class do not need to know how a schedule is implemented internally. You do not want that your clients are bounded to the implementation you chose to store internally a ScheduleData. Think, if you let your clients to access directly to the list, once you want to change the implementation using a Set, you will force them to change accordingly.
Moreover, following information hiding principle, you will reduce coupling between your class and clients, increasing maintainability.
So, with the information you gave us, the best you can do is probably use a method add directly defined on Schedule.
Another thing that I suggest you to change is the method
public List<ScheduleData> getList(){
return list;
}
Returning a direct reference to the internal list, you will allow anyone to change it without using the add method. Try to return an unmodifiable copy of the list, instead.
public List<ScheduleData> getList(){
return Collections.unmodifiableList(list);
}
Hope it helps.
My preference would be to use the add(ScheduleData data) method that you have written. I would recommend you avoid having a getter or getList() method for the List in your class, if you can avoid it.
The reason for this is that it provides some degree of encapsulation and better facilitates abstraction, which are considered desirable features of Object Oriented Programming.
Encapsulation is part of why classes are helpful. Your code will be much easier to understand and maintain if most of the logic for changing member variables is written in the class that contains them. Here is a typical introductory level explanation for encapsulation. You may notice that getters and setters are often talked about as a way to encapsulate. With fields that store object references, as in your example, it might be useful to think of how the getter is being used though. Personally i think that if you use a getter to obtain an object reference then write code elsewhere to set something inside your class, you are losing the benefits that encapsulation provides.
Abstraction is the process of discarding any information irrelevant to your task. The goal is to minimize the amount that a consumer of your class has to think about. It may be only you that will use the Schedule class but it will make your life easier if you don't need to remember exactly how it is implemented. If you use your add(ScheduleData data) method you may find working with the class far more intuitive down the road. Also any documentation for it will be simple...if anyone wants to add ScheduleData to their Schedule instance they will see that there is a method called add. If you consider the alternative, of looking at the member variables to see that there is a List, then looking at the documentation for List to find out how to add to it, you will probably see the benefits of using your add method.
Here is another article about getters and setters which are also referred to as accessors and mutators.